System and method for processing requests to alter system security databases and firmware stores in a unified extensible firmware interface-compliant computing device

ABSTRACT

A mechanism for allowing firmware in a UEFI-compliant device to implement the UEFI specification driver signing and Authenticated Variable elements while at the same time protecting the system security database holding the library of approved keys and lists of allowed and forbidden programs from unauthorized modifications is discussed.

RELATED APPLICATION

This application is related to and claims the benefit of U.S.provisional patent application No. 61/473,234, entitled “System andMethod for Processing Requests to Alter a System Security Database in aUnified Extensible Firmware Interface (UEFI)-Compliant Device, filed onApr. 8, 2011, the contents of which are incorporated herein by referencein their entirety.

BACKGROUND

Unified Extensible Firmware Interface (UEFI) is a specification createdby a non-profit industry body detailing a programming interface betweenthe Operating System and the included firmware of a computing devicesuch as (but not limited to) a Personal Computer (PC). UEFIspecifications describe a set of tools by which a computing device canmove in an organized fashion from the power-applied state to fullyoperational. The computing device is initialized by firmware includedwithin the device and this firmware provides a range of softwareservices which facilitate the boot of the operating system as well asproviding a smaller subset of these services that continue to beavailable after operating system has booted. The UEFI specificationtells the desired result but deliberately does not specify the internaltactic of implementation. The UEFI firmware specification replacesearlier OS/firmware interfaces previously used by the industry andcommonly known as legacy BIOS.

The UEFI specification provides a facility called driver signaturechecking by which software from other parties can be ‘signed’ usingpublic/private key cryptographic techniques at its origin. Thissignature is validated by the computing device firmware prior toallowing this software to operate. The signature checking concentrateson software added to configure optional components (plug-in boards) andsoftware supplied by the operating system for early boot steps (OS bootloaders). The signature checking is accomplished with a library ofapproved keys. The computing device must take care to not allowunauthorized software elements any ability to modify the library ofapproved keys as this would allow rogue software elements to defeat thesignature checking.

When implemented in a computing device, the machine codes for UEFIfirmware and all permanent data used by the firmware reside in Read OnlyMemory (ROM). In many cases the ROM is an Electrically Erasable silicondevice known as a flash ROM. Flash ROM has the characteristic that itcan be erased by electrical command and individual elements may then bewritten and the device will retain the data indefinitely. When power isfirst applied to the computing device, the system executes a processcalled reset which clears the state to a known condition and beginsexecution of the firmware. The firmware is read from the flash ROM.Among other services, the firmware is responsible for operation of thecomputing device until a boot process can be run which loads anoperating system for the computing device into memory. Once loaded, theoperating system is in charge of normal operation of the computingdevice. Of note, anti-virus programs for the computing device requirethe operating system to be loaded before they can function.

The contents of a Flash ROM may be logically partitioned into severalfunctional divisions or regions. One such region is the firmware storewhich includes the loadable image of startup firmware and securityfirmware modules and must be protected from alteration by any entityexcept for entities that have been authorized to update the firmwarestore. A second region called the Authenticated Variable Region or Storeholds Authenticated Variables defined in the UEFI specification and isused to hold UEFI-defined security information (the security database).In addition to the UEFI-defined information the Authenticated VariableStore can be used to store user-defined data related to the ultimateuses of the computer. Because it contains security data and potentiallysensitive user data the UEFI specification provides that theAuthenticated Variable Region/Store must be protected from alteration byany entity except those authorized by the presence of identifying keydata within the security database. A third region, the UEFI variablestore, contains lower security information which may be freely updatedby user programs. On various platforms certain other regions exist eachwith unique update restrictions and the method describe herein can beextended to protect against unauthorized modification to these regionsas well.

The computing device contains one or more elements known as CentralProcessing Units (CPU) which, when in operation, can read from and alsoperform input-output commands to erase and/or write the flash ROM. TheCPU has a normal operating mode and a second operating mode calledSystem Management Mode (SMM). When the CPU is in normal operating modeit can access all elements of the computer except certain memory regionsexclusively dedicated to SMM. In contrast, when the CPU is operating inSMM it is able to access all elements of the computing device includingthe dedicated memory. An electrical signal is made available within thecircuitry of the computing device which can indicate when the CPU isoperating within SMM. The CPU device may be directed to transition fromnormal operating mode to SMM by a number of triggers called SystemManage Interrupt (SMI) events including SMI events triggered byfirmware. The exact triggers available differ somewhat from among systemdesigns but the result when the platform appropriate trigger is used isalways that execution in main memory is immediately suspended andexecution begins at a specific location in SMM memory. Certain computingdevices also contain a hardware circuit that can detect if the system isin SMM and is able to disable flash ROM erase and write operations whenthe system is not in SMM.

Unfortunately, there exists today a wide variety of software created byunauthorized third parties with the explicit intent to damage or subvertthe proper operation of computing devices such as PCs. Given the names‘computer virus’ or ‘malware’, these rogue software elementsincreasingly target the boot process as a way to get control of acomputing device before preventive (e.g.: anti-virus) software hasloaded. Exemplary forms of boot attacking software are known asroot-kits or the ‘Trojan Boot Virus’.

There is a need to occasionally update the firmware and related datacontained in the flash ROM (or other ROM) without compromising securityof the computing device by allowing root kits or Trojan Boot virusesaccess to the firmware. While the Flash ROM may have intrinsicprotection devices known as block write enables, these are not suitablefor protection of a flash-resident data item that needs an update duringsystem operation while restricting the ability to perform the updateonly to those originated by a trusted authority. The intrinsic flash ROMprotection is generally composed of arrays of bits that when set preventwrites to a sub-region. This type of complete write prevention howeverdoes not allow selective updates performed by trusted authorities.

BRIEF SUMMARY

The embodiments of the present invention provide a mechanism forallowing firmware in a UEFI-compliant device to implement the UEFIspecification driver signature checking and Authenticated Variableelements while at the same time preventing unauthorized modification toregions of a flash ROM. By the process described herein protection fromunauthorized modification which would render the computing devicevulnerable to attack by malicious software is provided to a number ofsecurity-critical elements including: (1) the Authenticated Variableregion of the flash ROM containing the security database; (2) thoseportions of the flash ROM firmware store containing the loadable imageof the firmware modules; and (3) the executable image in SMM memory ofthe firmware modules which check authorization and perform updates tothe security database and firmware store regions of the flash ROM. Thesecurity database contained in the Authenticated Variable region holdsvarious information including the library of approved keys and lists ofallowed and forbidden programs while the portion of the firmware storecontaining the loadable image of the firmware modules includes both thestartup firmware and security firmware modules. More specifically, theembodiments of the present invention utilize firmware modules which areonly able to be accessed and executed when the CPU is in SMM. As aresult, the firmware modules of the present invention are hidden fromexamination and modification by an OS or user programs and may performthe security processing of the UEFI signature check and other techniquesin a manner difficult to observe or modify.

In one embodiment a method for processing system security databaserequests in a Unified Extensible Firmware Interface (UEFI)-compliantcomputing device includes the step of receiving a signed system securitydatabase modification request from an operating system module. Thesigned request seeks to perform an alteration of a system securitydatabase in the UEFI-compliant computing device. The request isprocessed by a firmware request reception module composed of code thatis accessible when a central processing unit (CPU) in the computingdevice is operating in a normal CPU mode. The method triggers atransition of the CPU from the normal CPU mode to a System ManagementMode (SMM) using the request reception module and verifies a legitimacyof the processed request for performing an alteration of a systemsecurity database with a firmware verification module that is onlyexecutable when the CPU is in SMM. The method additionally validates asignature contained in the processed request for performing analteration of the system security database. The validating occurs usinga firmware validation module that is only executable when the CPU is inSMM. The method performs the alteration of the system security databaserequested using a firmware update module following a successfulvalidation of the signature in the request. The firmware update moduleis only executable when the CPU is in SMM.

In another embodiment, a method for updating a firmware store region ina flash Read-Only Memory (ROM) in a Unified Extensible FirmwareInterface (UEFI)-compliant computing device includes receiving at theUEFI-compliant device a downloaded update package that includes anexecutable update program, a replacement image of the firmware store anda signed hash of the replacement image. The method also includes thestep of triggering with the update program, while a central processingunit (CPU) in the UEFI-compliant computing device is operating in anormal CPU mode, a transition of the CPU from the normal CPU mode to aSystem Management Mode (SMM). The method further validates the signatureand replacement image with SMM-resident firmware that is only executablewhen the CPU is in SMM and updates the firmware store with thereplacement image. The updating occurs using SMM-resident firmware thatis only executable when the CPU is in SMM.

In an embodiment, a Unified Extensible Firmware Interface(UEFI)-compliant computing device includes a central processing unit(CPU) configured to execute a firmware request reception module. Therequest reception module receives and processes a signed system securitydatabase modification request from an operating system module. Therequest seeks to perform an alteration of a system security database inthe UEFI-compliant computing device. The request reception module isexecutable when the CPU is operating in a normal CPU mode and triggers atransition of the CPU from the normal CPU mode to a System ManagementMode (SMM) after processing the received request. The CPU also executesa firmware verification module that verifies a legitimacy of theprocessed request for performing an alteration of a system securitydatabase. The firmware verification module executes only when the CPU isin SMM. The CPU further executes a firmware validation module. Thefirmware validation module validates a signature contained in theprocessed request for performing an alteration of the system securitydatabase. The firmware validation module also executes only when the CPUis in SMM. The CPU additionally executes a firmware update module. Thefirmware update module performs the requested alteration of the systemsecurity database following a successful validation of the signature.The firmware update module executes only when the CPU is in SMM.

In another embodiment, a Unified Extensible Firmware Interface(UEFI)-compliant computing device, includes a central processing unit(CPU) configured to execute a downloaded update package that includes anexecutable update program for updating a firmware store region in aflash Read-Only Memory (ROM) in the UEFI-compliant computing device. Theupdate package further includes a replacement image of at least part ofthe firmware store and a signed hash of the replacement image. Theupdate program triggers a transition of the CPU from a normal CPU modeto a System Management Mode (SMM). The CPU in the device also executesSMM-resident firmware for validating the signature and replacementimage. The SMM-resident firmware for validating the signature andreplacement image only executes when the CPU is in SMM mode.Additionally, the CPU in the device executes SMM-resident firmware forupdating the firmware store with the replacement image. The SMM-residentfirmware for updating the firmware store only executes when the CPU isin SMM mode.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more embodiments of theinvention and, together with the description, help to explain theinvention. In the drawings:

FIG. 1 depicts an exemplary sequence of steps performed by an embodimentof the present invention to utilize firmware modules in a UEFI compliantdevice;

FIG. 2 depicts an exemplary sequence of steps performed by an embodimentof the present invention to utilize firmware modules in a UEFI compliantdevice for the purpose of updating the firmware store of a flash ROM;and

FIG. 3 depicts an exemplary environment suitable for practicingembodiments of the present invention

DETAILED DESCRIPTION

Embodiments of the present invention provide a mechanism for aUEFI-compliant computing device to perform the driver signature checkingof software updates that is discussed in the UEFI specification in amanner which greatly limits the ability of malware to tamper with thelibrary of approved keys and other information held in the systemsecurity database. By limiting access to the Authenticated Variablesholding the system security database and associated information to thetechniques discussed herein, the security processing envisioned by UEFIcan be implemented by restricting the processing to occurring insideSMM. As SMM memory is hidden from examination by an OS or other program,the ability of unauthorized third parties to observe and then modify thesecurity process becomes significantly diminished.

One of the major security features of the UEFI specification is thatlists of allowed and forbidden programs, allowed or forbidden to performcertain types of software updates requiring signature checking, and theidentification of agents able to add to these lists, is maintained bythe UEFI-compliant computing device. However, if the computerinstructions to modify the lists and allow agents are present in normalmemory (accessible when the CPU is in normal operating mode), theability to determine the authenticity of the instructions is greatlycompromised as the instructions could be from malicious softwareoperating in the same memory space rather than from legitimate securitysoftware. The embodiments of the present invention address this issue byensuring that only software approved and checked by the manufacturer canbe resident in SMM memory and that all specified security updates areprocessed only when the CPU is in SMM.

The embodiments of the present invention close and lock access to SMMmemory prior to execution of any software not specified and loaded atthe factory with the factory image undergoing post-factory amendmentsonly as applied by the secure firmware update process described herein.This restriction on access and amendment greatly enhances the ability ofthe computing device to perform the signature checking envisioned in theUEFI specification. Through the use of firmware modules focused on thesecure processing of update requests, the updates may be handled so asto ensure the requests only originate from valid entities.

FIG. 1 depicts an exemplary sequence of steps performed by an embodimentof the present invention to utilize firmware modules in a UEFI compliantdevice. The sequence begins when a firmware request reception modulereceives a signed request for a software update that would require thealteration of an Authenticated Variable such as that variable holdingthe system security database that includes the library of approved keysused to perform signature checking (step 102). The request may bereceived via the UEFI run-time interface. Of note, the firmware requestreception module is operable and accessible when the CPU is operating innormal mode. Upon receiving the request, the firmware request receptionmodule checks the request format and saves certain memory locationinformation for the use of SMM-based code and causes the CPU totransition to SMM by a specific method appropriate to the systemplatform for the processing of the request (step 104). For example, insome systems the transition may be triggered by invocation of an SMIinterrupt. Once the CPU is operating in SMM, a firmware verificationmodule which only operates when the CPU is operating in SMM receives therequest and verifies that it is actually from the firmware requestreception module (step 106) by checking the location in memory of theSMM request against previously noted request reception module loadaddress and by examining the image of the Package module in memory toconfirm the image has not been altered. If the request is not verified,the request is denied (step 108). It will be appreciated that theinvalid request may trigger a displayed or logged alert, and the returnof a UEFI defined error code to software requesting the update. If therequest is verified as coming from the request reception module afirmware validation module that is only operable in SMM examines thesignature information included in the database update request andperforms signature checking using at least one key in the systemsecurity database (step 110). It should be noted that in otherembodiments the system can be operated in conditions of greater orlesser security and the exact policy or rules for signature checking maydiffer according to the state of the system. Regardless of thesevariations in condition however, for embodiments of the presentinvention, the currently applicable policy for signature checking isapplied by the SMM resident module according to the state informationrecorded in the protected system security database.

The computing device may utilize public/private key encryption as partof an Authenticated Variable update validation process. The updaterequest may include content and a signed hash of at least portions ofcontent, the hash being signed or encrypted, by a private key held bythe requesting entity. As part of the validation process, the validationmodule may recreate the hash of the portion of the update content thatwas signed using the same hashing algorithm, decrypt the signed hashwith a corresponding and authorized public key from the system securitydatabase and compare the original hash to the new hash. If an authorizedkey does not exist in the system security database and/or the hashes arenot identical, the request is not valid (step 112) and the update isrefused. If the request is determined to be valid, a firmware updatemodule that operates only when the CPU is in SMM processes the requestand updates the flash ROM (step 114).

In one embodiment, a non-secure firmware request reception module thatoperates when the CPU is in normal mode may be used to receive requestsfor updates to flash regions not protected by signature updaterestrictions. The non-secure request reception module may package therequests and invoke SMM for processing. Once SMM is invoked theserequests may be received and processed by a firmware module operating inSMM that performs the requested modifications to the non-secure regionof the flash ROM. This processing is performed because SMM-basedprotection of the flash is for the entire device or devices andtherefore all flash changes must be routed through SMM.

In one embodiment, the computing device may include a firmware modulethat controls the circuitry used to protect flash by the disable offlash erase and write operations that originate outside of SMM. Whenfirmware starts execution after power is applied to the computingdevice, the Flash protection circuitry is not operational. Therefore afirmware module is provided which performs platform-specific operationsto enable the flash protection circuitry at an appropriate point of bootoperation prior to the introduction of any untrusted firmware. Once set,the flash protection circuitry is not reversible except by reset.Because the system returns to trusted code obtained from the flash ROMat reset this algorithm ensures at no point in the operation of thesystem is the flash firmware store available for alteration by untrustedcode.

FIG. 2 depicts an exemplary series of steps to use the mechanismdescribed here to implement the process of updating all or a portion ofthe firmware store regions of the flash ROM. The process in general issimilar to that described in FIG. 1 allowing for the reuse of manycommon firmware components and the efficient use of firmware resourcesbut does include some differences. The sequence begins when a firmwareupdate package is downloaded to a UEFI-compliant device and executed(step 202). The update package includes several parts including anupdate launching program which is an executable program designed tofunction in the installed operating system. In addition to the updatelaunching program, the downloaded update package includes a replacementimage for all, or a selected portion, of the firmware store as well as adata block containing instructions to the update program including, butnot limited to, the system identifier of targeted system(s). The updatepackage also includes a signed hash of the replacement image. The signedhash of the new image and the data block is prepared by cryptographicmethods defined in the UEFI specification similarly to those describedabove for the signing of updates to the Authenticated Variable region.The bytes for all of the parts of the update package, are signed at theOEM site and checked by the firmware. The downloaded update package issigned in such a way as to make it possible for the firmware todetermine that no portion of the download has been modified after it wascreated.

In one embodiment, in addition to the components detailed above, thedownloaded package may also contain supplemental firmware modules toperform the actual process of erasing and writing the flash image. Thesupplemental firmware modules if present are also signed by the processdescribed above and validated similarly.

In more detail, the update launching program loads into memory andchecks the integrity of the other portions of the update package. If thedownload integrity check is successful the update launching programprepares memory location information for use in upcoming operations thatwill take place in SMM and signals a request to transition to SMM usinga method appropriate to the device platform being updated (step 204). Itwill be appreciated that there may be a number of similar updatelaunching programs each with different variations tailored to operate inspecific operating systems and to function correctly on the platform tobe updated within the scope of the present invention. As a result of therequest, the CPU transitions to SMM via a platform appropriate technique(step 204). In one embodiment, once the CPU has switched to SMM, thefirmware verification module which operates only within SMM may receivethe update request and verify the identity of the requesting updatelaunching program (step 206). For example, the request may be verifiedby checking the location in memory of the SMM request against apreviously noted update launching program load address and by examiningthe image of the update package in memory to confirm the image has notbeen altered. If the request is not verified (step 207), the request andupdate are denied (steps 208 and 212) in which case the CPU returns tonormal memory mode with an error code. On the other hand, if the requestis verified (step 207), a firmware validation module which operates onlyin SMM attempts to validate the update request by verifying thereplacement firmware image using the signed hash. There may be one orpotentially multiple public keys resident in the factory-installed flashROM image that are enabled for validation of firmware update imagesignatures. These keys reside in one of the protected regions but may ormay not reside in the Authenticated Variable region according to theparticular requirements of the system. The SMM-resident firmwarevalidation module that receives the update request first performs thecryptographic checks required to verify that the update submitted by theupdate program was signed by a private key authorized to performfirmware updates. Only if the cryptographic checks pass will the updatebe passed along to the firmware responsibility for erasing and writingthe firmware store region, otherwise the update will be denied (step212). On the other hand, following a successful validation, a firmwareupdate module that is only executable when the CPU is in SMM updates thefirmware store (step 214). Following the update of the firmware store,the UEFI-device will reboot before returning to normal memory with asuccess code for the update operation. In some embodiments, foradditional security, additional security precautions may be taken. Forexample, in one embodiment, the UEFI-device may reboot followingvalidation and before the firmware update is performed. Upon returningto the update process, the update package may again be validated beforethe update is performed. In such an implementation, the UEFI devicewould reboot a second time following the update before returning tonormal memory.

The actual erasing and writing of the flash ROM can require a number ofseconds and while the system is in SMM it is not responsive to otheruser programs. So as to provide a better user experience when largeupdates are required, in one embodiment, the actual processing of theupdate may be broken into smaller portions by the mechanism of returningto the caller in main memory—either the variable update packager or theupdate program, with a flag indicating partial completion. This break inoperation may potentially occur several times. After receiving thispartial completion flag, the caller suspends operation for some brieftime period to allow other user programs to briefly execute and thenreenters SMM with a continuation flag. In the case of the update programa visual progress indication on the user screen may be updated uponreturn to main memory. Upon re-entry to SMM, the SMM firmware takes anysteps required to make sure that the memory image of the update inprogress was not modified during the suspension. This optional step isomitted from FIGS. 1 and 2 only for clarity.

FIG. 3 depicts an exemplary environment suitable for practicingembodiments of the present invention. A UEFI-compliant computing device300 includes a CPU 302 able to operate in normal mode and SMM. Thecomputing device 300 which may be a PC, laptop computer, tabletcomputing device, server, smartphone or some other type of computingdevice equipped with a processor and able to comply with therequirements of the UEFI specification. The computing device 300 mayalso include a memory 304 such as Random Access Memory (RAM). Anoperating system 312 stored on a hard drive or equivalent mass storagedevice, in, or in communication with, computing device 300, may beloaded into memory 304 as part of a boot process performed by thecomputing device.

The computing device 300 may also include flash ROM 320. In some casesthe system design may incorporate multiple flash ROM devices. In theevent multiple flash ROM devices are employed, all of the flash ROMdevices may be accessed using the same procedures and subject to thesame security process as set forth above. Flash ROM 320 may includefirmware modules as described above that are operable at differentpoints of the computing device's operation. For example, flash ROM 320may include a firmware request reception module 321 that is operablewhen the CPU 302 is in a normal operation (non-SMM operation) 340. Theflash ROM 320 may also hold a firmware verification module 322, afirmware validation module 323 and a firmware update module 324 that areoperable only when the CPU is operating in SMM 350. Although thedescription herein describes the firmware verification module 322,firmware validation module 323 and firmware update module 324 asseparate modules, it should be appreciated that the functionality of themodules may be combined into a lesser or greater number of moduleswithout departing from the scope of the present invention.

The flash ROM 320 may be logically partitioned into several functionalregions. Thus, flash ROM 320 may include authenticated variables region330 holding system security database 331. System security database 331holds authorized keys used for signature checking as set forth in theUEFI specification and is only accessible when the CPU is operating inSMM 350. Similarly, flash ROM 320 may also include firmware store 332which holds the loadable image of start up and security firmware modules333. Flash ROM 320 may also include UEFI variable store region 334. Itshould be appreciated that flash ROM 320 may be logically divided toinclude other regions different from or encompassing the regionsdiscussed herein in a different manner without departing from the scopeof the present invention.

Embodiments of the present invention may be provided in whole or in partas one or more non-transitory computer-readable programs embodied on orin one or more physical mediums. For example, the mediums may be afloppy disk, a hard disk, a compact disc, a digital versatile disc,flash memory, a PROM, an MRAM, a RAM, a ROM, or a magnetic tape. Ingeneral, the computer-readable programs may be implemented in anyprogramming language. Some examples of languages that can be usedinclude FORTRAN, C, C++, C#, Python, ActionScript, JavaScript, or Java.The software programs may be stored on, or in, one or more mediums asobject code. Hardware acceleration may be used and all or a portion ofthe code may run on a FPGA, an Application Specific Integrated Processor(ASIP), or an Application Specific Integrated Circuit (ASIC). The codemay run in a virtualized environment such as in a virtual machine.Multiple virtual machines running the code may be resident on a singleprocessor.

Since certain changes may be made without departing from the scope ofthe present invention, it is intended that all matter contained in theabove description or shown in the accompanying drawings be interpretedas illustrative and not in a literal sense. Practitioners of the artwill realize that the sequence of steps and architectures depicted inthe figures may be altered without departing from the scope of thepresent invention and that the illustrations contained herein aresingular examples of a multitude of possible depictions of the presentinvention. Specifically it is noted that within certain embodiments, thesteps described in FIG. 2 may be modified or replaced by comparableprocesses without requiring changes to the steps of FIG. 1. Further,while the description herein discusses various functionality attributedto specific software modules for ease of explanation, it will beappreciated that the modules may be named differently or combined ordivided in a manner not specifically discussed so as to deliver the samefunctionality without departing from the scope of the present invention.

The foregoing description of example embodiments of the inventionprovides illustration and description, but is not intended to beexhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the invention. Forexample, while a series of acts has been described, the order of theacts may be modified in other implementations consistent with theprinciples of the invention. Further, non-dependent acts may beperformed in parallel.

1. A method for processing system security database requests in a Unified Extensible Firmware Interface (UEFI)-compliant computing device, comprising: receiving a signed system security database modification request from an operating system module, the request seeking to perform an alteration of a system security database in the UEFI-compliant computing device, the request processed by a firmware request reception module, the request reception module being executable when a central processing unit (CPU) in the computing device is operating in a normal CPU mode: triggering a transition of the CPU from the normal CPU mode to a System Management Mode (SMM) using the request reception module; verifying a legitimacy of the processed request for performing an alteration of a system security database with a firmware verification module that is only executable when the CPU is in SMM; validating a signature contained in the processed request for performing an alteration of the system security database, the validating occurring using a firmware validation module that is only executable when the CPU is in SMM; and performing the alteration of the system security database requested using a firmware update module, the alteration occurring following a successful validation of the signature, the firmware update module only executable when the CPU is in SMM.
 2. The method of claim 1 wherein the firmware validation module validates the signature in the request for performing an alteration of a system security database using a key stored in the system security database.
 3. The method of claim 1, further comprising: saving, with the firmware request reception module, memory location information related to the request for performing an alteration of a system security database for the use of the firmware verification module, the memory location information saved prior to triggering the transition to SMM.
 4. The method of claim 3 wherein the verifying is performed by the firmware verification module checking the saved location in memory against a previously noted request reception module load address.
 5. The method of claim 1 wherein the firmware request reception module, firmware verification module, firmware validation module, firmware update module and the system security database are stored in flash ROM.
 6. A method for updating a firmware store region in a flash Read-Only Memory (ROM) in a Unified Extensible Firmware Interface (UEFI)-compliant computing device, comprising: receiving at the UEFI-compliant device a downloaded update package that includes an executable update program, a replacement image of the firmware store and a signed hash of the replacement image; triggering with the update program, while a central processing unit (CPU) in the UEFI-compliant computing device is operating in a normal CPU mode, a transition of the CPU from the normal CPU mode to a System Management Mode (SMM); validating the signature and replacement image with SMM-resident firmware that is only executable when the CPU is in SMM; and updating the firmware store with the replacement image, the updating occurring using SMM-resident firmware that is only executable when the CPU is in SMM.
 7. The method of claim 6 wherein the UEFI-compliant device re-boots or shuts down following the validating and prior to the updating of the firmware store.
 8. The method of claim 6, further comprising: saving, with the update program, memory location information related to the update package, the memory location information saved prior to triggering the transition to SMM.
 9. A non-transitory computer-readable medium holding computer-executable instructions for processing system security database requests in a Unified Extensible Firmware Interface (UEFI)-compliant computing device, the instructions when executed causing at least one computing device to: receive a signed system security database modification request from an operating system module, the request seeking to perform an alteration of a system security database in the UEFI-compliant computing device, the request processed by a firmware request reception module, code for the request reception module being accessible when a central processing unit (CPU) in the computing device is operating in a normal CPU mode: trigger a transition of the CPU from the normal CPU mode to a System Management Mode (SMM) using the request reception module; verify a legitimacy of the processed request for performing an alteration of a system security database with a firmware verification module that is only executable when the CPU is in SMM; validate a signature contained in the processed request for performing an alteration of the system security database, the validating occurring using a firmware validation module that is only executable when the CPU is in SMM; and perform the alteration of the system security database requested using a firmware update module, the alteration occurring following a successful validation of the signature, the firmware update module only executable when the CPU is in SMM.
 10. The medium of claim 9 wherein the firmware validation module validates the signature in the request for performing an alteration of a system security database using a key stored in the system security database.
 11. The medium of claim 9, wherein the instructions when executed further cause the computing device to: save, with the firmware request reception module, memory location information related to the request for performing an alteration of a system security database for the use of the firmware verification module, the memory location information saved prior to triggering the transition to SMM.
 12. The medium of claim 11 wherein the verifying is performed by the firmware verification module checking the saved location in memory against a previously noted request reception module load address.
 13. A non-transitory computer-readable medium holding computer-executable instructions for updating a firmware store region in a flash Read-Only Memory (ROM) in a Unified Extensible Firmware Interface (UEFI)-compliant computing device, the instructions when executed causing at least one computing device to: receive at the UEFI-compliant device a downloaded update package that includes an executable update program, a replacement image of the firmware store and a signed hash of the replacement image; trigger with the update program, while a central processing unit (CPU) in the UEFI-compliant computing device is operating in a normal CPU mode, a transition of the CPU from the normal CPU mode to a System Management Mode (SMM); validate the signature and replacement image with SMM-resident firmware that is only executable when the CPU is in SMM; and update the firmware store with the replacement image, the updating occurring using SMM-resident firmware that is only executable when the CPU is in SMM.
 14. The medium of claim 13 wherein the UEFI-compliant device re-boots or shuts down following the validating and prior to the updating of the firmware store.
 15. The medium of claim 13 wherein the instructions when executed further cause the computing device to: save, with the update program, memory location information related to the update package, the memory location information saved prior to triggering the transition to SMM.
 16. A Unified Extensible Firmware Interface (UEFI)-compliant computing device, comprising a central processing unit configured to execute: a firmware request reception module, the request reception module receiving and processing a signed system security database modification request from an operating system module, the request seeking to perform an alteration of a system security database in the UEFI-compliant computing device, the request reception module being executable when a central processing unit (CPU) in the computing device is operating in a normal CPU mode and triggering a transition of the CPU from the normal CPU mode to a System Management Mode (SMM) following the processing; a firmware verification module, the firmware verification module verifying a legitimacy of the processed request for performing an alteration of a system security database, the firmware verification module executing only when the CPU is in SMM; a firmware validation module, the firmware validation module validating a signature contained in the processed request for performing an alteration of the system security database, the firmware validation module executing only when the CPU is in SMM; and a firmware update module, the firmware update module performing the requested alteration of the system security database following a successful validation of the signature, the firmware update module executing only when the CPU is in SMM.
 17. The device of claim 16 wherein the firmware validation module validates the signature in the request for performing an alteration of a system security database using a key stored in the system security database.
 18. A Unified Extensible Firmware Interface (UEFI)-compliant computing device, comprising a central processing unit (CPU) configured to execute: a downloaded update package including an executable update program for updating a firmware store region in a flash Read-Only Memory (ROM) in the UEFI-compliant computing device, the update package further including a replacement image of at least part of the firmware store and a signed hash of the replacement image, the update program triggering a transition of the CPU from normal CPU mode to a System Management Mode (SMM); SMM-resident firmware for validating the signature and replacement image, the SMM-resident firmware for validating the signature and replacement image only executing when the CPU is in SMM; and SMM-resident firmware for updating the firmware store with the replacement image, the SMM-resident firmware for updating the firmware store only executing when the CPU is in SMM. 